Update vendored zlib to 1.3.2#1443
Conversation
Refresh vendored zlib sources, headers, documentation, and minizip files to upstream v1.3.2 so the SDK tracks the current supported zlib release. Preserve the SDK's symbol-prefix shim and legacy Windows project wiring, and update the zlib CMake shim so out-of-source builds no longer mutate zconf.h or define Windows macros on non-Windows hosts. Files changed: - cgmanifest.json - zlib core sources, headers, docs, and minizip support files - zlib/names.h and zlib/CMakeLists.txt repo-specific shims Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Is it possible to move some (or all) of these to somewhere outside of zlib? For example, the vcxproj could move to third_party/Solutions/zlib (lining up with my hope of moving zlib itself to third_party/zlib) -- that would make it clear what the changes are. Very similar to the PR you just did regarding resetting zlib to a clean copy. |
Keep the vendored zlib folder closer to the upstream 1.3.2 layout while preserving the legacy MSBuild project used by the Windows solution. Files changed: - Move vc14 zlib Visual Studio projects to third_party/Solutions/zlib/vc14 - Update solution, sample, and test ProjectReference paths - Remove unused vc9/vc10/vc11 zlib project directories Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Done in I also checked whether the prefix shim could move out cleanly. I kept |
| <ClInclude Include="..\..\..\zlib.h" /> | ||
| <ClInclude Include="..\..\..\zutil.h" /> | ||
| <ClInclude Include="..\..\..\..\zlib\deflate.h" /> | ||
| <ClInclude Include="..\..\..\..\zlib\infblock.h" /> |
There was a problem hiding this comment.
Non-blocking: these headers infblock.h / infcodes.h / infutil.h are stale entries. These already existed before this move, so I do not think this is a regression. They should only matter if something actually tries to include/use those headers. Longer term, as we move away from carrying a repo-owned zlib snapshot, we should clean up this kind of stale project wiring too. No action needed as of now, just flagging it for now.
lalitb
left a comment
lalitb
left a comment
There was a problem hiding this comment.
LGTM. Nice work.
One observation - I noticed our internal vcpkg port may drift from this zlib update because it has its own pinned source and patch. I think the vcpkg port is already stale in lots of areas, so worth keeping in mind for later cleanup if we continue to carry that port.
Summary
da607da739fa6047df13e66a2af6b8bec7c2a498).zlib/closer to the upstream layout while preserving the repo-specific integrations that are still required:zlib/contrib/vstudio/vc14and intothird_party/Solutions/zlib/vc14, then update the solution, SDK project, sample, and test references to the new location. Upstream zlib 1.3.2 removed the pre-made Visual Studio project directories, but this repo still builds zlib through the legacyzlibvc.vcxprojpath fromSolutions/MSTelemetrySDK.sln, SDK projects, samples, and tests.zlib/contrib/vstudio/vc9,vc10, andvc11directories from the vendored zlib tree.act_z_symbol-prefix shim throughzlib/names.hand the#include "names.h"hooks inzconf.h,zconf.h.in, andzconf.h.cmakein. This still needs to be visible from zlib's public/config headers while the repo uses a prefixed vendored zlib.gzgetcprefix handling ingzread.c/zlib.h; this remains tied to the customact_z_prefix map because using upstream'sZ_PREFIX_SETpath directly would break zlib'sdeflateInit/inflateInitmacro behavior for this repo's prefix scheme.zconf.hand non-Windows builds do not get Windows-only macros.